The present invention relates to efficient evaluation of queries using in-memory databases, and in particular to optimizing in-memory data management for variant configuration.
Many different products are offered for sale with numerous available features that define particular product variants. Historically, customers may have been offered features that were added to a standard product, or they may have been allowed certain feature omissions or substitutions. One customer may prefer to add air conditioning to a car as an “option” when air conditioning is not a standard product feature for example, while another customer may prefer a convertible car that omits the standard product's hard top. The manufacturer may decide that since few customers are likely to order convertible cars with air conditioning, that product variant may not be offered for sale. A potential customer who wanted such a product variant would therefore be disappointed, and a revenue opportunity may be missed.
The trend toward full customization of a product line has therefore become increasingly popular, along with more flexible manufacturing. The potentially very large number of product features that may specify particular product variants complicates information management for sales, engineering, and production. Variant configuration tools therefore help ensure that a particular product variant having the desired features may be provided. Such tools may prevent problems such as the specification of mutually exclusive product characteristics or product feature combinations that are not offered for sale or are not available for assembly or delivery at a given price or by a given schedule.
One aspect of variant configuration management is the preparation of a bill of materials (BOM), which is a complete, formally structured list of all the lowest-level components needed to produce a particular product line, including all possible provided product variants. BOM preparation or “explosion” is an often difficult and time-consuming process. Rather than simply creating a separate BOM for each of many possible variants, manufacturers may instead use configurable BOMs that describe the required component parts for an entire product line as functions of specified product variant features. These functions can become quite complicated for fully customized products with many user-selectable features. A database may be needed to manage the mapping of the desired features that define the variant configuration and all the components that each variant requires.
In one database model of a configurable BOM, a product feature or characteristic may be used to distinguish one component part from another. A characteristic may include a component name and a component quantity. For example, a component name of “color” with a component quantity of “red” could distinguish one laptop computer case from another. Each component may have many characteristics, such as “left”, “rear”, “LED”, and country of origin “Japan” for a particular car tail light. Each characteristic of each component may be used as part of a selection condition to identify the required components of a product variant. Although described above in terms of product assembly from component parts, configuration management issues may also arise in many other situations, and may involve different types of components, such as pieces of equipment, routings, documents, etc. Further, although selection conditions are familiar to consumers when choosing products, in this description selection conditions are used as exemplary cases of a more general object dependency.
Evaluation of the possibly very complex object dependencies during manufacturing resource planning (MRP) and other processes is very time critical. The fastest available databases thus may be required. In-memory databases that primarily operate on data stored in a computer system's main memory tend to be faster than older databases that required significant external secondary storage input/output operations. In-memory databases may also perform data operations other than calculations (i.e., comparisons, transfers, etc.) much faster than they perform calculations. An example of an in-memory database is SAP's High Performance Analytics Appliance (HANA™) database.
The execution speed of in-memory database operations may however be strongly dependent on the arrangement of data. Unfortunately, the evaluation of object dependencies is not currently optimized for column store databases. Time-consuming processes like BOM explosion management may currently only be optimized for conventional row store databases in scenarios without variant configuration. This limitation severely restricts the utility of such in-memory tools.
Accordingly, the inventors have developed an improved approach to evaluation of variant configuration using in-memory technology.